摘要
Day 25 把 Day 24 的 AuditEvent / Provenance readiness evidence 往前推一步：report 不只列出 input SHA-256、contract、gate outcome 和各 evidence layer 狀態，現在也會產生 request-scoped FHIR R4 AuditEvent 與 Provenance JSON preview。Day 25 的重點不是 production audit workflow，而是讓 Quality Test Report 可以證明：未來若要接 persistent audit log 或外部 FHIR repository，最小 FHIR resource shape 已經存在。

這和「能不能交換」有什麼關係？

Day 24 可以回答：

如果下一步要落地 AuditEvent / Provenance，最小 evidence 欄位在哪裡？

但正式交換前還有一個更具體的問題：

這些 evidence 欄位能不能形成實際 FHIR R4 AuditEvent / Provenance resource？

如果一個 quality gate 只能顯示文字 evidence，卻無法把 validation action、input hash、contract version、gate outcome 和各 readiness layer 狀態組成 FHIR resource，那它離 audit / provenance integration 還差一層。

Day 25 的目標不是變成 production audit platform。
Day 25 的目標是：

Audit / Provenance readiness evidence -> request-scoped FHIR resource preview

也就是說，今天新增的是「可落地的 audit / provenance resource shape」：

• 不是 persistent audit log。
• 不是把 AuditEvent / Provenance 寫到外部 FHIR server。
• 不是正式 Consent / operator identity / SMART scope audit。
• 不是保存 uploaded Bundle 或 server responses。
• 而是先讓 report 能證明：系統可以用 HAPI FHIR R4 model 產生最小 AuditEvent / Provenance JSON preview。

例如同一份 Bundle 進來時，Day 25 的判斷會是：

這讓 report 可以明確說明：

AuditEvent / Provenance 已能生成 request-scoped FHIR preview。
但目前只展示，不持久化也不提交。

今天的實作範圍

Day 25 的 request / report flow 變成：

使用者上傳 Bundle
   │
   ├─ 執行原本 JSON / FHIR / TW Core / contract rules
   │
   ├─ terminology server evidence
   │     ├─ ValueSet/$expand
   │     └─ ValueSet/$validate-code
   │
   ├─ live FHIR metadata evidence
   │     └─ GET {FHIR_BASE_URL}/metadata
   │
   ├─ sandbox readiness evidence
   │     ├─ non-PHI preflight
   │     ├─ sandbox auth boundary
   │     └─ CapabilityStatement interaction declarations
   │
   ├─ privacy / retention evidence
   │     ├─ masked field categories
   │     └─ retention policy = request-scoped only / no persistent history
   │
   └─ AuditEvent / Provenance resource preview
         ├─ input SHA-256
         ├─ selected contract id/version
         ├─ gate outcome
         ├─ rule count
         ├─ terminology status
         ├─ metadata status
         ├─ sandbox status
         └─ generation policy = generated request-scoped only; not persisted; not submitted

最後 Quality Test Report 的 evidence layer 變成：

Quality Gate blocking result
   ├─ FHIR / TW Core / contract local rules
   ├─ Terminology server evidence
   ├─ Live FHIR metadata evidence
   ├─ Sandbox readiness evidence
   ├─ Privacy / retention evidence
   └─ AuditEvent / Provenance resource preview evidence
        ├─ AuditEvent JSON preview
        ├─ Provenance JSON preview
        └─ generation policy

AuditEvent preview 做到哪裡？

Day 25 新增的 AuditEvent 是 request-scoped preview。

它會記錄：

• validation action。
• input SHA-256。
• selected contract display name。
• gate outcome。
• contract rule count。
• terminology evidence status。
• live metadata evidence status。
• sandbox preflight status。
• resource generation policy。

AuditEvent.outcome 目前對應：

這不是在宣稱已完成正式 audit workflow。
Day 25 的 AuditEvent preview 不包含：

• operator identity。
• authenticated user/session。
• SMART launch context。
• OAuth scope。
• Consent decision。
• external server write result。
• persistent audit id。

它只是把 Day 24 的 readiness 欄位整理成 FHIR R4 AuditEvent resource preview，讓下一步可以接 persistent audit 或 external FHIR write。

Provenance preview 做到哪裡？

Day 25 新增的 Provenance 也是 request-scoped preview。

它會記錄：

• report preview target。
• quality gate report generation activity。
• system agent：TW Lab Contract Gate。
• hashed input Bundle source：urn:sha256:{inputHash}。
• contract / gate / terminology / metadata / sandbox 狀態衍生資訊。

這個 layer 的定位是：

report generation provenance evidence
不是 production resource lineage repository

原因是 Day 25 還沒有 database-backed history、stable report id、operator identity、access control、retention deletion workflow，也沒有把 Provenance 寫入外部 FHIR server。

JSON preview 怎麼產生？

Day 25 不手刻 JSON 字串。

今天新增 AuditProvenanceResourceService，用 HAPI FHIR R4 model 建立：

• org.hl7.fhir.r4.model.AuditEvent
• org.hl7.fhir.r4.model.Provenance

然後再透過 HAPI JSON parser serialize。

這讓 preview 至少具備兩個 evidence：

resource shape 來自 FHIR R4 model
JSON serialization 來自 HAPI parser

report 只顯示 readonly preview：

• AuditEvent resource preview
• Provenance resource preview

Privacy / retention 邊界維持什麼？

Day 25 不把 raw Bundle 寫入 AuditEvent 或 Provenance。

preview 使用：

urn:sha256:{inputHash}

來指向輸入 Bundle 的 hash。

它不應輸出：

• Patient.name
• Patient.identifier.value
• Patient.telecom
• Patient.address
• Patient.birthDate
• raw Bundle JSON

Generation policy 明確顯示：

generated request-scoped only; not persisted; not submitted

這表示目前版本仍然不會把 uploaded Bundle、terminology response、FHIR metadata response、sandbox response、AuditEvent 或 Provenance 寫進資料庫，也不會送到外部 FHIR server。

今天新增的主要類別

• AuditProvenanceResourceService
• AuditProvenanceResources

AuditProvenanceReadinessResult 也新增三個欄位：

• auditEventJson
• provenanceJson
• resourceGenerationPolicy

AuditProvenanceReadinessService 從單純文字 readiness evidence，改成同時呼叫 resource generation service 產生 request-scoped preview。

測試重點

今天新增測試確認：

• generated AuditEvent JSON 可被 HAPI parse 回 AuditEvent。
• generated Provenance JSON 可被 HAPI parse 回 Provenance。
• AuditEvent preview 包含 input SHA-256、contract、gate outcome、rule count、terminology status、metadata status、sandbox status。
• Provenance preview 使用 urn:sha256:{inputHash} 指向 hashed Bundle source。
• preview JSON 不包含 raw Bundle 或 direct Patient identifier 類欄位。
• report UI 顯示 AuditEvent resource preview。
• report UI 顯示 Provenance resource preview。
• report UI 顯示 generated request-scoped only; not persisted; not submitted。

目前測試結果：

Tests run: 101, Failures: 0, Errors: 0, Skipped: 0

Day 25 完成後的邊界

完成後，專案的定位變成：

pre-exchange quality gate
   ├─ FHIR / TW Core validation
   ├─ partner contract rules
   ├─ contract lifecycle / compatibility
   ├─ unit normalization evidence
   ├─ terminology server evidence
   ├─ metadata preflight
   ├─ sandbox readiness evidence
   ├─ privacy / retention evidence
   └─ request-scoped AuditEvent / Provenance preview

但它仍然不是：

• production exchange platform。
• full SMART/OAuth client。
• live resource read/search executor。
• Bundle submitter。
• persistent audit log。
• external FHIR AuditEvent / Provenance writer。
• PHI repository。
• retention deletion workflow。

下一步

之後預計從 Day 25 的 preview 往下做：

• 真正的 SMART/OAuth sandbox token flow。
• non-PHI test patient fixture / workflow。
• allowlisted live Patient / Observation / DiagnosticReport read/search execution checks。
• external FHIR AuditEvent / Provenance write policy。
• formal PHI masking policy。
• database-backed persistent history。
• retention deletion workflow。
• deeper terminology governance，例如 inactive code policy、CodeSystem version、UCUM algebra。

Repository：twcore-data-quality-gate